Architectures for secure portable executable content

The Java programming language supports the concept of downloadable executable content; a key technology in a wide range of emerging applications including collaborative systems, electronic commerce, and Web information services. Java enables the execution of a program, on almost any modern computer regardless of hardware configuration and operating system. Safe-Tcl was proposed as an executable content type of MIME and thus as the standard language for executable contents within e-mail messages. However, the ability to download, integrate, and execute code from a remote computer, provided by both Java and Safe-Tcl, introduces serious security risks since it enables a malicious remote program to obtain unauthorised access to the downloading system’s resources. In this paper, the two proposed security models are described in detail and the efficiency and flexibility of current implementations are evaluated in a comparative manner. Finally, upcoming extensions are discussed. Internet Research: Electronic Networking Applications and Policy Volume 9 · Number 1 · 1999 · pp. 16–24 © MCB University Press · ISSN 1066-2243 they have fewer capabilities than the users who invoked them. The Safe-Tcl security model makes it possible to implement highly restrictive security policies for scripts of unknown origin as well as less restrictive policies for scripts whose authors are known and trusted. This paper evaluates the security features offered by the Java and Safe-Tcl programming languages and describes the basic mechanisms of each of the proposed security models. We present and compare the current implementations as well as upcoming extensions of the two security models, and evaluate their efficiency and flexibility. Although Microsoft’s Active-X technology also supports downloadable executable content and is based on an interesting security architecture it is not examined in this article because, in its current implementation, it is operating system and hardware specific. The Java security model Java was created to enable the development of programs in a heterogeneous network-wide environment. It allows Java-compatible Web browsers to download code fragments dynamically and then execute those code fragments on the local machine. Executable portability, meaning that a Java program (or applet) is portable not only in source code but also in compiled binary code, was therefore one of the major design goals of Java. The Java Virtual Machine (JVM), a system that simulates an abstract machine, is the part of the Java-compatible Web browser that provides this portability layer (Sun Microsystems, 1997a;1997b). The JVM architecture defines an instruction set, a register set, a stack, a garbage-collected heap, and a memory area. This architecture allows a single executable to run unmodified on many different systems. To achieve this, the Java compiler compiles Java code to an architecture independent object file format containing JVM code (or bytecodes), which is then interpreted by a processor-specific JVM implementation or compiled on the fly into the machine code of the particular processor. The aim of the Java security model is to protect users from malicious applets originating from untrusted sources across a network. Java provides a customisable “sandbox”, which is a dedicated area of the Web browser within which the actions of the applet are restricted. Within its sandbox the applet may do anything but access the user’s files, network connections, and other sensitive resources. The basic idea of the sandbox model is that programs loaded from the local file system are executed with full access to vital system resources, whereas executable content downloaded from a remote source is considered untrusted, and can therefore access only the limited resources provided inside the sandbox. The first release of the Java Development Kit (JDK 1.0) was based on the above described mechanism of the sandbox model. Overall security is enhanced through a number of mechanisms. First, the language itself was designed with security in mind so that every program that conforms to the language specification, automatically obeys basic low level security restrictions (Yellin, 1995). The most important features that make the Java language attractive as an environment to write safe code are the lack of pointer arithmetic, mandatory array bounds-check at runtime, the prohibition of casts of primitive types into reference types, and the automatic garbage collection. Security is provided by the JVM during the loading and verification of the JVM code. Applets are loaded from the network by the applet Class Loader which receives the bytecode instruction stream and converts it into internal data structures that represent the applet’s classes. The class loader, apart from fetching an applet’s executable content from the network, also enforces the name space hierarchy. By maintaining a separate name space for trusted code which was loaded from the local disk, the Class Loader prevents untrusted applets from gaining access to more privileged, trusted parts of the system. The bytecode verifier is invoked by the Class Loader, and before the execution of the newly imported applet, ensures that the applet conforms to the specifications of the Java language, and that there are no violations of name space restrictions or of memory accesses. The bytecode verifier, along with the properties of the JVM, guarantee language safety at runtime. The third component of the Java security model is the Security Manager, which restricts the way in which an applet can use visible interfaces by performing run-time checks on dangerous 17 Architectures for secure portable executable content Stefanos Gritzalis, George Aggelis and Diomidis Spinellis Internet Research: Electronic Networking Applications and Policy Volume 9 · Number 1 · 1999 · 16–24